home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19990422-19990725
/
000151_news@watsun.cc.columbia.edu _Sun Jun 13 15:05:22 1999.msg
< prev
next >
Wrap
Internet Message Format
|
1999-07-23
|
4KB
Return-Path: <news@watsun.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id PAA02025
for <kermit.misc@watsun.cc.columbia.edu>; Sun, 13 Jun 1999 15:05:22 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id OAA16251
for kermit.misc@watsun.cc.columbia.edu; Sun, 13 Jun 1999 14:35:39 -0400 (EDT)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Subject: Re: Zmodem U/L to BBS
Date: 13 Jun 1999 18:35:38 GMT
Organization: Columbia University
Message-ID: <7k0tlq$fro$1@newsmaster.cc.columbia.edu>
To: kermit.misc@watsun.cc.columbia.edu
In article <SrS83.1275$y92.347@news.rdc1.ct.home.com>,
Bob Bernstein <ruptured-duck@home.com> wrote:
: I'm observing some odd behaviour exchanging QWK reply packets via zmodem
: with a local BBS. This is a Linux system, running C-Kermit 7.0.195
: Beta.06. I have to add I see the same behaviour if I use minicom, but I want
: to stick to using Kermit, and my guess's I have a better chance of fixing
: this if I do.
:
: Problem: there's a long pause between sending the .rep packet and the BBS
: deciding to unzip it, and the pause includes the BBS sending what I
: interpret to be more requests for the zmodem upload to commence. The packet
: gets sent immediately when I issue the command 'send chowda.rep', but it
: seems the board doesn't know I through sending. Here's a screen shot of a
: typical session:
:
Which shows you gave the BBS menu command to [U]pload, escaped back to
C-Kermit, and gave a SEND command. You had obviously given a prior SET
PROTOCOL ZMODEM command to C-Kermit, so it ran the sz program (or whatever
your Zmodem external protocol program is) to send the file. The upload
evidently succeeds but...
: When I reconnect with the BBS after doing the send, things just sit there
: for a looong time as those two additional '**B000......' strings get sent.
:
Actually the strings you said you saw were:
**B0887010000b908
**B0887010000b908
Most Zmodem implementations will let you cancel out of this state by typing
five (5) consecutive Ctrl-X characters.
: tia for any light shed on this! (btw, the 'CX123456-Z' is a phonied version
: of my Cox Cable machine name. I've gotta change my prompt string!)
:
I don't have a ready answer, since I can't see this with my own eyes.
The aforementioned strings are the ones sent by Zmodem when it is waiting
for a file. But you already sent it the file it was waiting for, so why
does it want another one?
It's hard to say without knowing how the BBS works. One guess would involve
C-Kermit's "autoupload strings":
C-Kermit>set proto zmomdem
C-Kermit>sho proto
Protocol: ZMODEM
Executed by external commands:
SEND command (binary): sz %s
SEND command (text): sz -a %s
RECEIVE command (binary): rz
RECEIVE command (text): rz
Autoreceive command (binary): rz
Autoreceive command (text): rz
C-Kermit>
These are described in the External Protocols chapter of "Using C-Kermit".
If you "set protocol zmodem", the autoreceive strings shown above are loaded
by default. So when you give a SEND command, C-Kermit first sends "rz" (and
carriage return), and then sends the file with sz (or sz -a if the file type
is text).
But maybe sending the "rz" command to your BBS makes it enter receive mode
a second time. So when setting C-Kermit's protocol to Zmodem, try doing it
like this:
set protocol zmodem {} {}
to disable the "autoupload" strings, as shown on p.282 of the manual. Or
substitute whatever else is appropriate for the BBS.
- Frank